Personally I think it would be neat. For example the admin-tool guys
would be able to get a dump without invoking an external program.
Second it would really be independent of core releases (other than being
tied to the output format.) pg_dump would be just a simple caller of
such a library, and
It probably wouldn't be terribly difficult to put the guts of pg_dump
into a library that you could interface with via C. I'm not sure if the
community would accept such a patch; though, I seem to recall other
people asking for this on occasion.
I think script support is bit risky because if an
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> And even then you better have a pretty high correlation on the first
> column, otherwise you'll still get a seqscan.
Not with the LIMIT. (If he were fetching the whole table, very possibly
the sort would be the right plan anyway.)
On Thu, Jun 08, 2006 at 03:20:55PM -0400, Tom Lane wrote:
> "Andrus" <[EMAIL PROTECTED]> writes:
> > Why Postgres 8.1 does not use makse_kuupaev_idx index in the following
> > query
> > ?
>
> Because it doesn't help --- the system still has to do the sort.
> You'd need a two-column index on both
Actually It looks to me like the sorting is the slow part of this query.
Maybe if you did create an index on both kuupaev and kellaaeg it might
make the sorting faster. Or maybe you could try increasing the server's
work mem. The sort will be much slower if the server can't do the whole
thing in
"Andrus" <[EMAIL PROTECTED]> writes:
> Why Postgres 8.1 does not use makse_kuupaev_idx index in the following query
> ?
Because it doesn't help --- the system still has to do the sort.
You'd need a two-column index on both of the ORDER BY columns to avoid
sorting.
regards
More precisely - the Postgres could use the index to speed up the
sorting, but in this case the sorting is very fast (less than one
second according to the output), so Postgres probably decided not
to use the index because it would be slower.
Btw. have you run ANALYZE on the table recently? What i
If you want to benefit from the usage of an index, the query has to
contain some WHERE conditions (on the indexed columns). This is a
'select all' query - there is no way to speed it up using index.
Tomas
> > Why Postgres 8.1 does not use makse_kuupaev_idx index in the
following query
> > ?
> >
>
Why Postgres 8.1 does not use makse_kuupaev_idx index in the following query
?
How to speed this query up ?
explain analyze select * from makse order by kuupaev desc, kellaaeg desc
limit 100
"Limit (cost=62907.94..62908.19 rows=100 width=876) (actual
time=33699.551..33701.001 rows=100 loops=
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Any explanation for this horror?
Existing releases aren't smart about planning joins to inheritance
trees.
Using a view that UNIONs SELECT .. ONLY as replacement for the parent
table isn't any better. Is that improved too?
CVS
Jim C. Nasby wrote:
> On Thu, Jun 08, 2006 at 06:33:28PM +0200, Andreas Pflug wrote:
> > Alvaro Herrera wrote:
> >
> > >
> > >
> > >Personally I think it would be neat. For example the admin-tool guys
> > >would be able to get a dump without invoking an external program.
> > >Second it would real
On Thu, Jun 08, 2006 at 06:33:28PM +0200, Andreas Pflug wrote:
> Alvaro Herrera wrote:
>
> >
> >
> >Personally I think it would be neat. For example the admin-tool guys
> >would be able to get a dump without invoking an external program.
> >Second it would really be independent of core releases (
Alvaro Herrera wrote:
Personally I think it would be neat. For example the admin-tool guys
would be able to get a dump without invoking an external program.
Second it would really be independent of core releases (other than being
tied to the output format.) pg_dump would be just a simple cal
Jim C. Nasby wrote:
> On Thu, Jun 08, 2006 at 11:39:48AM +0530, soni de wrote:
> > We have to take a backup of database and we know the pg_dump utility of
> > postgresql.
> >
> > But may I know, is there any API for this pg_dump utility so that we can
> > call it from the C program? Or only script
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Any explanation for this horror?
Existing releases aren't smart about planning joins to inheritance
trees. CVS HEAD is better...
regards, tom lane
---(end of broadcast)---
TIP 3:
Tom Lane wrote:
"soni de" <[EMAIL PROTECTED]> writes:
We have to take a backup of database and we know the pg_dump utility of
postgresql.
But may I know, is there any API for this pg_dump utility so that we can
call it from the C program? Or only script support is possible for this.
There's
On Thu, Jun 08, 2006 at 01:40:33PM +0200, Andreas Pflug wrote:
> I have this table setup on a 8.1.4 server:
>
> pj_info_attach(attachment_nr, some more cols) -- index, 50k rows
> pj_info_attach_compressable() INHERITS (pj_info_attach) -- index, 1M rows
> pj_info_attach_not_compressable() INHERITS
On Thu, Jun 08, 2006 at 11:39:48AM +0530, soni de wrote:
> We have to take a backup of database and we know the pg_dump utility of
> postgresql.
>
> But may I know, is there any API for this pg_dump utility so that we can
> call it from the C program? Or only script support is possible for this.
"soni de" <[EMAIL PROTECTED]> writes:
> We have to take a backup of database and we know the pg_dump utility of
> postgresql.
> But may I know, is there any API for this pg_dump utility so that we can
> call it from the C program? Or only script support is possible for this.
There's always system
"soni de" <[EMAIL PROTECTED]> writes:
> One more thing I have to mention is that we are using 2 postmasters running
> on different machines and both are accessing same data directory. (i.e both
> the machines uses same tables or the databases)
The above is guaranteed NOT to work. I'm surprised yo
I have this table setup on a 8.1.4 server:
pj_info_attach(attachment_nr, some more cols) -- index, 50k rows
pj_info_attach_compressable() INHERITS (pj_info_attach) -- index, 1M rows
pj_info_attach_not_compressable() INHERITS (pj_info_attach) -- index, 0
rows
EXPLAIN ANALYZE SELECT aes FROM pj
21 matches
Mail list logo
