[PERFORM] performance discrepancy indexing one column versus two columns

All, In the psql output below, I would expect the second query to run faster, because the b-tree index on two columns knows the values of 'b' for any given value of 'a', and hence does not need to fetch a row from the actual table. I am not seeing a speed-up, however, so I expect my

Re: [PERFORM] performance discrepancy indexing one column versus

On Sun, 11 Sep 2005, Mark Dilger wrote: All, In the psql output below, I would expect the second query to run faster, because the b-tree index on two columns knows the values of 'b' for any given value of 'a', and hence does not need to fetch a row from the actual table. I am not seeing a

[PERFORM] Index not used with prepared statement

Hi. I have a performance problem with prepared statements (JDBC prepared statement). This query: PreparedStatement st = conn.prepareStatement(SELECT id FROM dga_dienstleister WHERE plz like '45257'); does use an index. This query: String plz = 45257; PreparedStatement

Re: [PERFORM] Index not used with prepared statement

Guido Neitzer schrob: I have a performance problem with prepared statements (JDBC prepared statement). This query: PreparedStatement st = conn.prepareStatement(SELECT id FROM dga_dienstleister WHERE plz like '45257'); does use an index. This query: String plz = 45257;

Re: [PERFORM] Index not used with prepared statement

On 11.09.2005, at 11:03 Uhr, Andreas Seltenreich wrote: I'm not perfectly sure, but since the index could only be used with a subset of all possible parameters (the pattern for like has to be left-anchored), I could imagine the planner has to avoid the index in order to produce an universal

Re: [PERFORM] shared buffers

Martin Nickel wrote: Chris, Would you say that 3 pages is a good maximum for a Postgres install? We're running 8.0.3 on 64-bit SUSE on a dual Opteron box with 4G and have shared_buffers set at 12. I've moved it up and down (it was 16 when I got here) without any measurable

[PERFORM] LEFT JOIN optimization

Hi list, I don't have much experience with Postgres optimization, somehow I was happily avoiding anything more difficult than simple select statement, and it was working all right. Now LEFT JOIN must be used, and I am not happy with the performance: It takes about 5 seconds to run very simple

Re: [PERFORM] LEFT JOIN optimization

* Ksenia Marasanova ([EMAIL PROTECTED]) wrote: Any tips are greatly appreciated. EXPLAIN ANALYZE of the same queries would be much more useful. Thanks, Stephen signature.asc Description: Digital signature

Re: [PERFORM] LEFT JOIN optimization

2005/9/12, Stephen Frost [EMAIL PROTECTED]: * Ksenia Marasanova ([EMAIL PROTECTED]) wrote: Any tips are greatly appreciated. EXPLAIN ANALYZE of the same queries would be much more useful. Thanks, here it is: test=# explain analyze select * from user_ left join church on user_.church_id =

Re: [PERFORM] LEFT JOIN optimization

* Ksenia Marasanova ([EMAIL PROTECTED]) wrote: test=# explain analyze select * from user_ left join church on user_.church_id = church.id; [...] Total runtime: 2025.946 ms (6 rows) test=# set enable_seqscan='false'; SET test=# explain analyze select * from user_ left join church on

Re: [PERFORM] Prepared statement not using index

Guido Neitzer wrote: Hi. I have an interesting problem with the JDBC drivers. When I use a select like this: SELECT t0.aktiv, t0.id, t0.ist_teilnehmer, t0.nachname, t0.plz, t0.vorname FROM public.dga_dienstleister t0 WHERE t0.plz like ?::varchar(256) ESCAPE '|' withBindings: 1:53111(plz)

Re: [PERFORM] Advise about how to delete entries

Kevin wrote: Arnau wrote: Hi all, COPY FROM a file with all the ID's to delete, into a temporary table, and do a joined delete to your main table (thus, only one query). I already did this, but I don't have idea about how to do this join, could you give me a hint ;-) ? Thank