Thread: Replication/Clustering Solution

Replication/Clustering Solution

From
"guillermo schulman"
Date:
Hi you all.
I'm asked to do a report about Replication/Clustering for PostgreSQL. I need
to report about what kind of tools do exist and compare them, and finally
propose a solution to implement in the company's database.
I have a poor idea about replication/clustering issues (and about writing
english, you can see it), so I'd be glad to be helped by you.
Here is a brief description of our model:
There are a lot of "component servers" (CS) that provide the frontend
services. These CS hosted in diferent servers work with databases hosted in
the unique main "database server".
We are adding periodically more CS because the growing number of users.
Adding these CS solves succesfully the scalability problem in this point of
view, but the database is becoming over-required due this situation.
So, I need to look for solution on database to solve the following problems:
- scalability as the 1st priority.
- reliability as the second priority (system failure, disaster avoiding,
etc).
- performance as a future problem to solve (phisically distributed CS with
local/remote access).
So, which kind of solution, orientated on Replication/Clustering, are
available for ProspectSql? And which are the "pros and cons" for each one
for our priorities to solve?

Thanks, and sorry for my english.

_________________________________________________________________



Funny results in query

From
Chris Pizzo
Date:
Hi all,
can someone explain why this is happening?

select field1, field2, field3, field4, field5, field6, field7, field8,
field9, field10, field11, field12, field13, field14 from table where
field18 = 't' order by  us_retail_price asc offset 48 limit 6;

returns...
field1
------------+
H1205
B1494
B1496
H1204
B1495
B1497

but ...

select field1, field2, field3, field4, field5, field6, field7, field8,
field9, field10  from table where field18 = 't' order by  us_retail_price
asc offset 48 limit 6;

returns...
field1
------------+
  H1180
  H1179
  H1205
  B1496
  H1204
  B1497

it appears the number of fields i have in the select is affecting the
results.  I don't understand why?

running 7.2.1

Thanks in advance,
Chris



Re: Funny results in query

From
Tom Lane
Date:
Chris Pizzo <chris@artinside.com> writes:
> can someone explain why this is happening?

> select field1, field2, field3, field4, field5, field6, field7, field8,
> field9, field10, field11, field12, field13, field14 from table where
> field18 = 't' order by  us_retail_price asc offset 48 limit 6;
> [returns different results from]
> select field1, field2, field3, field4, field5, field6, field7, field8,
> field9, field10  from table where field18 = 't' order by  us_retail_price
> asc offset 48 limit 6;

Is 'order by us_retail_price' a unique ordering of the rows?  (I'd bet
not.)  If not, the server is entitled to sort rows of equal price
however it wants.  It's an extremely bad idea to use limit/offset
without an order-by clause that *completely* determines the row
ordering, because otherwise the results are unspecified.

> it appears the number of fields i have in the select is affecting the
> results.  I don't understand why?

Could have something to do with the number of rows that fit into
sort_mem at one time.

            regards, tom lane