On Fri, May 1, 2009 at 8:29 PM, PFC wrote:
> Roundtrips can be quite fast but they have a hidden problem, which is
> that everything gets serialized.
The client and server will serialize, but what usually matters most is
avoiding serializing against disk I/O--and that's why write-back
cach
On Sat, 2 May 2009, PFC wrote:
Blocking round trips to another process on the same server should be
fairly cheap--that is, writing to a socket (or pipe, or localhost TCP
connection) where the other side is listening for it; and then
blocking in return for the response. The act of writing to an
Blocking round trips to another process on the same server should be
fairly cheap--that is, writing to a socket (or pipe, or localhost TCP
connection) where the other side is listening for it; and then
blocking in return for the response. The act of writing to an FD that
another process is wait
On 5/1/09 7:32 AM, "henk de wit" wrote:
> Hi,
>
> I was looking at the support that PostgreSQL offers for table partitioning
> at http://www.postgresql.org/docs/8.4/static/ddl-partitioning.html. The
> concept looks promising, but its maybe fair to say that PG itself doesn't
> really supports par
Gerhard Wiesinger writes:
> FROM
>log l
> -- Order is relevant here
> LEFT OUTER JOIN key_description k1 ON k1.description = 'Raumsolltemperatur'
> LEFT OUTER JOIN log_details d1 ON l.id = d1.fk_id AND d1.fk_keyid =
> k1.keyid
Surely this query is just plain broken? You're forming a c
I looked into the distribution of the filenames, in particular I ran a
query to see how for into the table the 1st filename would be found.
photoshelter=# select count(*) from ps_image where lower(file_name) <
'a-400-001.jpg';
count
-
8915832
As you can see the first row is al
On Fri, May 1, 2009 at 10:32 AM, henk de wit wrote:
> I was looking at the support that PostgreSQL offers for table partitioning
> at http://www.postgresql.org/docs/8.4/static/ddl-partitioning.html. The
> concept looks promising, but its maybe fair to say that PG itself doesn't
> really supports p
The 'in' form and 'join' form produce identical plans for both limit
and non-limit versions of the query, which I actually think reflects
well on the query planner. I also tried a form of the query with the
subselect in the from clause to try and force the order the tables
were evaluated
I had tried using exists but both the forms of the query (with limit
and without) performed much worse.
James
On May 1, 2009, at 4:22 AM, Adam Ruth wrote:
You could try changing the IN to an EXISTS, that may alter how the
optimizer weighs the limit.
SELECT ID FROM ps_image WHERE EXI
James Nelson writes:
> Hi, I'm hoping you guys can help with improving this query I'm having
> a problem with. The main problem is that the query plan changes
> depending on the value of the LIMIT clause, with small values using a
> poor plan and running very slowly. The two times are roughl
Hi,
I was looking at the support that PostgreSQL offers for table partitioning at
http://www.postgresql.org/docs/8.4/static/ddl-partitioning.html. The concept
looks promising, but its maybe fair to say that PG itself doesn't really
supports partitioning natively, but one can simulate it using s
Hello,
I want to use postgresql for data entries (every minute) from a central heating
system where the timestamp is logged in a table log. For flexibility in the
future for future values and for implementing several high level types I've
modelled the values in a separate key/value table calle
EXISTS won't help much either, postgresql is not too fast, when it
comes to that sort of approach.
join is always going to be fast, it is about time you learn joins and
use them ;)
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
use join instead of where in();
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
You could try changing the IN to an EXISTS, that may alter how the
optimizer weighs the limit.
SELECT ID FROM ps_image WHERE EXISTS (SELECT null FROM
ps_gallery_image WHERE gallery_id ='G7ejKGoWS_cY' and image_id =
ps_image.id) ORDER BY LOWER(FILE_NAME) ASC
On 30/04/2009, at 3:51 AM,
Hi, I'm hoping you guys can help with improving this query I'm having
a problem with. The main problem is that the query plan changes
depending on the value of the LIMIT clause, with small values using a
poor plan and running very slowly. The two times are roughly 5 minutes
for the bad pl
16 matches
Mail list logo