Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
2. I had first dismissed Neil's idea of transactional sequence updates
as impossible, but on second look it could be done. Suppose RESTART
IDENTITY does this for each sequence;
* obtain AccessExclusiveLock;
* assign a new
Currently eqsel assumes that, except for the values stored as mcv's,
the number of times that a value appears in a table column is
independent of it's value. Unfortunately, this often yields
inappropriate selectivity estimates and frequently leads to
inappropriate plans.
As an example, consider
Nathan Boley [EMAIL PROTECTED] writes:
... There are two potential problems that I see with this approach:
1) It assumes the = is equivalent to = and = . This is certainly
true for real numbers, but is it true for every equality relation that
eqsel predicts for?
The cases that
Hi,
We've been making noises about dealing with TOAST tables as separate
entities in autovacuum for some time now. So here's a proposal:
Let's do it.
That's about it :-)
The only change of some consideration is that we will need two passes
over pg_class to get the list of relations to vacuum,
Mark Kirkwood [EMAIL PROTECTED] writes:
IFAIK (dimly recalling numerical analysis courses at university) SUM and ROUND
can *never* be commuted. In general the recommended approach is to round as
late as possible and as few times are possible - so your 1st query is the
correct or best way to
Joshua D. Drake [EMAIL PROTECTED] writes:
On Fri, 2008-06-06 at 20:19 -0400, Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
Actually, the reason it's still 10 is that the effort expended to get it
changed has been *ZERO*. I keep asking for someone to make some
measurements, do some
Alvaro Herrera [EMAIL PROTECTED] writes:
The only change of some consideration is that we will need two passes
over pg_class to get the list of relations to vacuum, instead of one as
we do currently. The problem is that we first need to fetch the
(heap relid, toast relid) mapping before
On Saturday 07 June 2008 16:22:56 Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Perhaps we need a GUC that says expert_mode = on. ... Another idea
might be to make such command options superuser only, to ensure the
power is available, yet only in the hands of, by-definition, the
On Sunday 08 June 2008 19:07:21 Gregory Stark wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
On Fri, 2008-06-06 at 20:19 -0400, Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
Actually, the reason it's still 10 is that the effort expended to get it
changed has been *ZERO*. I
One of the areas where libpq seems to be severely lacking is in handling
arrays and composites in query results. I'd like to set about rectifying
that.
Ideally this would mean that drivers using libpq could easily and
reliably deliver such objects suitably structured in their particular
Andrew Dunstan [EMAIL PROTECTED] writes:
One complicating factor I see is that there is no protocol level support
for anything other than simple objects - each data value is simply a
stream of bytes of a known length. We would therefore need some pretty
robust processing to pick apart
Robert Treat [EMAIL PROTECTED] writes:
and i'm sure no one is against that idea, but you're never going to be able
to
match the performance of just avoiding the check.
We'll never be able to match the performance of not having transactions,
either, but the community has never for a moment
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
The only change of some consideration is that we will need two passes
over pg_class to get the list of relations to vacuum, instead of one as
we do currently. The problem is that we first need to fetch the
(heap relid, toast relid)
Alvaro Herrera [EMAIL PROTECTED] writes:
The point here is that if the user disables autovac for the main table,
then it's expected that it is automagically disabled for the toast table
as well, for the usual case where they are disabling it because the
table is too big.
Hmm, good point. OK,
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
One complicating factor I see is that there is no protocol level support
for anything other than simple objects - each data value is simply a
stream of bytes of a known length. We would therefore need some pretty
robust processing
On Sunday 08 June 2008 20:12:15 Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
and i'm sure no one is against that idea, but you're never going to be
able to match the performance of just avoiding the check.
We'll never be able to match the performance of not having transactions,
So while tagging the upcoming releases, I got annoyed once again about
what a tedious, error-prone bit of donkeywork it is. You've got to find
and update the sub-version numbers, and *not* any chance occurrence of
the same strings (eg s/20/21/g for version 7.4.21 would've mangled some
copyright
Tom Lane wrote:
I'm tempted to suggest letting the script invoke autoconf, too,
but that would require standardizing where to find the correct
version of autoconf for each branch; so it might not be such a
great idea.
Unfortunately that's true. Maybe we could agree on using an
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm tempted to suggest letting the script invoke autoconf, too,
but that would require standardizing where to find the correct
version of autoconf for each branch; so it might not be such a
great idea.
Unfortunately that's true.
Alvaro Herrera wrote:
We've been making noises about dealing with TOAST tables as separate
entities in autovacuum for some time now. So here's a proposal:
Let's keep it simple. Why not just adding a toast_enabled flag (disabled
by default) in pg_autovacuum? If it's set then main and toast
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Sunday, June 08, 2008 21:27:03 -0400 Tom Lane [EMAIL PROTECTED] wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm tempted to suggest letting the script invoke autoconf, too,
but that would require standardizing where to
Euler Taveira de Oliveira wrote:
FYI, I have a WIP patch to remove pg_autovacuum in favor of reloptions.
Really? Please send it my way to review/apply as soon as you have it
ready, independently of what we do with toast tables.
Let's keep it simple. Why not just adding a toast_enabled flag
Andrew Dunstan wrote:
One of the areas where libpq seems to be severely lacking is in handling
arrays and composites in query results. I'd like to set about rectifying
that.
Ideally this would mean that drivers using libpq could easily and
reliably deliver such objects suitably structured
Alvaro Herrera [EMAIL PROTECTED] writes:
Euler Taveira de Oliveira wrote:
And based on your proposal, it'll be needed to add reloptions to toast
tables too. IMO, we should keep that code as simple as possible.
Sure, what's the problem with that? We only need to make sure that
ALTER TABLE
24 matches
Mail list logo
